Skip to content
This repository has been archived by the owner on Mar 14, 2023. It is now read-only.

Fix add_spk API #118

Merged
merged 3 commits into from
Jan 10, 2023
Merged

Fix add_spk API #118

merged 3 commits into from
Jan 10, 2023

Conversation

rajarshimaitra
Copy link
Collaborator

Check if the spk already exists. If yes, returns false, or else add the spk into map and returns true

Fixes #98

Check if the spk already exists. If yes, returns false, or else add the
spk into map and returns true
@codecov-commenter
Copy link

codecov-commenter commented Dec 28, 2022

Codecov Report

Merging #118 (46524ad) into master (b6a9886) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #118   +/-   ##
=======================================
  Coverage   59.39%   59.39%           
=======================================
  Files           8        8           
  Lines         266      266           
=======================================
  Hits          158      158           
  Misses        108      108           
Impacted Files Coverage Δ
bdk_chain/src/keychain/keychain_txout_index.rs 0.00% <ø> (ø)
bdk_chain/src/lib.rs 100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@LLFourn
Copy link
Owner

LLFourn commented Dec 29, 2022

Thaks @rajarshimaitra. Shall we also change the name to insert_script_pubkey to be consistent with the other apis?

@rajarshimaitra
Copy link
Collaborator Author

Done..

Copy link
Collaborator

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK 6a39119

I like how this is looking.

@@ -37,13 +37,15 @@ pub mod collections {
#![allow(dead_code)]
pub type HashSet<K> = alloc::collections::BTreeSet<K>;
pub type HashMap<K, V> = alloc::collections::BTreeMap<K, V>;
pub use alloc::collections::btree_map::Entry;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should remove this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why though.. We can, but then we need to specify which::Entry at call site and feature gate it.. Not creating feature gated collection imports is what this module was intended to solve.. But maybe I am missing something.. Do you have a better way to call entry without explicit import?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If someone wants to import both bdk_core::collections::Entry (which is only a btree_map::Entry) and std::collections::hash_map::Entry at the same time, it will get messy. I think having to explicitly state which Entry it is, is a good-to-have.

Copy link
Collaborator Author

@rajarshimaitra rajarshimaitra Jan 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. I think I am getting what you are saying.. I tried it out but unfortunately this particular Entry itself will have three variants depending on feature list.. And different parent modules are available with different features.. So there's no way to do it without different feature gating combination at each module we wanna call Entry in.. It seems to me this way of consolidating all required imports is better than having various feature gates in different modules.. If later on we want to use both kinda Entry together we can explicitly import and give different names to them here in collections module. like use::std::collections::btree_map::Entry as StdBtreeEntry or something like that..

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can make hash_brown a non-optional dependency if that helps.

pub use alloc::collections::*;
}

// When we have std use `std`'s all collections
#[cfg(all(feature = "std", not(feature = "hashbrown")))]
#[doc(hidden)]
pub mod collections {
pub use std::collections::hash_map::Entry;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think this should be removed.

@@ -55,4 +57,5 @@ pub mod collections {
pub type HashSet<K> = hashbrown::HashSet<K>;
pub type HashMap<K, V> = hashbrown::HashMap<K, V>;
pub use alloc::collections::*;
pub use hashbrown::hash_map::Entry;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pub use hashbrown::hash_map::Entry;
pub use hashbrown::hash_map;

I think this would make more sense, then the above two lines can be removed and everything will be consistent.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly are you referring as inconsistent?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant that you can remove the two lines above without resulting in inconsistency.

Copy link
Collaborator Author

@rajarshimaitra rajarshimaitra Jan 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing as here #118

Copy link
Owner

@LLFourn LLFourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just need to sort out the Entry export thing. I think you can just export the hash_map module from each thing and import it has collections::hash_map::Entry?

bdk_chain/src/spk_txout_index.rs Outdated Show resolved Hide resolved
bdk_chain/src/spk_txout_index.rs Outdated Show resolved Hide resolved
@@ -37,13 +37,15 @@ pub mod collections {
#![allow(dead_code)]
pub type HashSet<K> = alloc::collections::BTreeSet<K>;
pub type HashMap<K, V> = alloc::collections::BTreeMap<K, V>;
pub use alloc::collections::btree_map::Entry;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can make hash_brown a non-optional dependency if that helps.

Import `hash_map` module from each category and call `collections::hash_map::Entry`
at call site.

plus some nit fixes.
@rajarshimaitra
Copy link
Collaborator Author

@LLFourn updated as suggestied. Let me know if this is how you meant to import..

We can make hash_brown a non-optional dependency if that helps.

Could be, but what we have currently doesn't seem to be bad either..

Copy link
Owner

@LLFourn LLFourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 46524ad

Copy link
Collaborator

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@LLFourn LLFourn merged commit e9ac33e into LLFourn:master Jan 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make SpkTxOutIndex::add_spk handle duplicate spks under different indexes
4 participants